Software development is a young profession, and we are still learning the techniques and building the tools to do it effectively. I've been involved in this activity for over three decades and in the last two I've been writing on this website about patterns and practices that make it easier to build useful software. The site began as a place to put my own writing, but I also use it to publish articles by my colleagues.
In 2000, I joined Thoughtworks, where my role is to learn about the techniques that we've learned to deliver software for our clients, and pass these techniques on to the wider software industry. As this site has developed into a respected platform on software development, I've edited and published articles by my colleagues, both Thoughtworkers and others, to help useful writing reach a wider audience.
photo: Christopher Ferguson
Martin Fowler
If there's a theme that runs through my work and writing on this site, it's the interplay between the shift towards agile thinking and the technical patterns and practices that make agile software development practical. While specifics of technology change rapidly in our profession, fundamental practices and patterns are more stable. So writing about these allows me to have articles on this site that are several years old but still as relevant as when they were written.
As software becomes more critical to modern business, software needs to be able to react quickly to changes, allowing new features to be conceived, developed and put into production rapidly. The techniques of agile software development began in the 1990s and became steadily more popular in the last decade. They focus on a flexible approach to planning, which allows software products to change direction as the users' needs change and as product managers learn more about how to make their users effective. While widely accepted now, agile approaches are not easy, requiring significant skills for a team, but more importantly a culture of open collaboration both within the team and with a team's partners.
This need to respond fluently to changes has an important impact upon the architecture of a software system. The software needs to be built in such a way that it is able to adapt to unexpected changes in features. One of the most important ways to do this is to write clear code, making it easy to understand what the program is supposed to do. This code should be divided into modules which allow developers to understand only the parts of the system they need to make a change. This production code should be supported with automated tests that can detect any errors made when making a change while providing examples of how internal structures are used. Large and complex software efforts may find the microservices architectural style helps teams deploy software with less entangling dependencies.
Creating software that has a good architecture isn't something that can be done first time. Like good prose, it needs regular revisions as programmers learn more about what the product needs to do and how best to design the product to achieve its goals. Refactoring is an essential technique to allow a program to be changed safely. It consists of making small changes that don't alter the observable behavior of the software. By combining lots of small changes, developers can revise the software's structure supporting significant modifications that weren't planned when the system was first conceived.
Software that runs only on a developer's machine isn't providing value to the customers of the software. Traditionally releasing software has been a long and complicated process, one that hinders the need to evolve software quickly. Continuous Delivery uses automation and collaborative workflows to remove this bottleneck, allowing teams to release software as often as the customers demand. For Continuous Delivery to be possible, we need to build in a solid foundation of Testing, with a range of automated tests that can give us confidence that our changes haven't introduced any bugs. This leads us to integrate testing into programming, which can act to improve our architecture.
San Francisco
There are many kinds of software out there, the kind I'm primarily engaged is Enterprise Applications. One of the enduring problems we need to tackle in this world is data management. The aspects of data managment I've focused on here are how to migrate data stores as their applications respond to changing needs, coping with different contexts across a large enterprise, the role of NoSQL databases, and the broader issues of coping with data that is both Big and Messy.
A common problem in complex software systems is how to capture complicated domain logic in a way that programmers can both easily manipulate and also easily communicate to domain experts. Domain-Specific Languages (DSLs) create a custom language for a particular problem, either with custom parsers or by conventions within a host language.
I've written seven books on software development, including Refactoring, Patterns of Enterprise Application Architecture, and UML Distilled. I'm also the editor of a signature series for Addison-Wesley that includes five jolt award winners.
I'm often asked to give talks at conferences, from which I've inferred that I'm a pretty good speaker - which is ironic since I really hate giving talks. You can form your own opinion of my talks by watching videos of some my conference talks.
I've long been a fan of board games, I enjoy a game that fully occupies my mind, clearing out all the serious thoughts for a bit, while enjoying the company of good friends. Modern board games saw dramatic improvement in the 1990's with the rise of Eurogames, and I expect many people would be surprised if they haven't tried any of this new generation. I also appear regularly on Heavy Cardboard.
If you'd like to be notified when I post new material, subscribe to my RSS feed. I also post announcements of new material to Fediverse (Mastodon), Bluesky, LinkedIn, and X (Twitter) . I also have a page dedicated to recent changes.
Wed 28 May 2025 09:50 EDT
Here's one of the best tips I know for writers, which was told to me by Bruce Eckel.
Once you've got a reasonable draft, read it out loud. By doing this you'll find bits that don't sound right, and need to fix. Interestingly, you don't actually have to vocalize (thus making a noise) but your lips have to move.
Fri 23 May 2025 13:48 EDT
At goto copenhagen last year, my friend James Lewis interviewed me and Goto have just released the video. I talk about when I learned about iterative design from Kent Beck, the dangers of product owners interfering with business-developer communication, and writing the agile manifesto. During this he specifically asked about my essay Is Design Dead. There's also a some audience questions asking if pair programming is a bad thing for introverts like us (no), and (inevitably) the role of LLMs for programmers today.
Tue 20 May 2025 09:20 EDT
Threat modeling is a systems engineering practice where teams examine how data flows through systems to identify what can go wrong - a deceptively simple act that reveals security risks that automated tools cannot anticipate. Often this is done by security analysts as a separate or upfront activity, but Jim Gumbley wrote an article in 2020 explaining how it could be done by teams through small and regular work.
Now Gayathri Mohan has joined Jim to rewrite the article, incorporating what both have them learned about doing and teaching this practice in the last few years. In particular they have extended their approach to perform threat modeling with platform teams.
Wed 14 May 2025 10:10 EDT
Tools that treat diagrams as code, such as PlantUML, are invaluable for communicating complex system behavior. But Unmesh Joshi often wished for an extension to walk through these diagrams step-by-step. Yet, extending established tools like PlantUML often involves significant initial setup - parsing hooks, build scripts, viewer code, packaging - enough “plumbing” to deter rapid prototyping.
He narrates now he used an LLM to build a small extension adding step-wise playback to PlantUML sequence diagrams. This illustrates how syntax design, parsing, SVG generation, build automation, and an HTML viewer were iteratively developed through a conversation with an LLM - turning tedious tasks into manageable steps.
Tue 13 May 2025 09:11 EDT
We have long recognized that developer environments represent a weak point in the software supply chain. Jim Gumbley and Lilly Ryan explore how agentic coding assistants expand the attack surface of software supply chains and what measures we need to do to safeguard security when using them.
Tue 06 May 2025 09:02 EDT
While LLMs excel at generating cogent text based on their training data, they may also need to interact with external systems. Kiran Prakash describes how we get them to construct external function calls to do this. The LLM does not execute these calls directly, instead it creates a data structure that describes the call, passing that to a separate program for execution and further processing. The LLM's prompt includes details about possible function calls and when they should be used.
Wed 30 Apr 2025 09:54 EDT
Creating a user interface that visualizes a real-world structure — like the Thirty Meter Telescope's mirror — might seem like a task that demands deep knowledge of geometry, D3.js, and SVG graphics. But with a Large Language Model (LLM) like Claude or ChatGPT, you don't need to know everything upfront. Unmesh Joshi describes how working with an LLM gave him a working prototype even when he's unfamiliar with the underlying tech.